
CONTROLLING RESOURCE GROUP TRANSFERS 
FOR REPO BASKET TRANSACTION SYSTEMS 



5 BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

The present invention relates to repo basket transaction systems and 
methods, and more generally, to systems and methods for controlling transfers 
of a group of resources which are defined in association with a condition under 
10 which, after the resource group transfer has been completed, a reverse 
transfer of the same or a similar group of resources has to occur. 

2. Description of the Related Art 

Such resource group transfers may take place in various technical fields. For 
example, resources may be memory resources in computer systems, and 

15 such memory resources may be allocated groupwise for some reasons. Other 
examples relate to the allocation of processing time as resources in, e.g., 
distributed network systems. In such systems, any resource allocation may be 
made dependent on a condition under which a reverse transfer of the same or 
a similar group of resources has to occur. However, prior art systems are 

20 often disadvantageous in that the definition of such transfers is usually rather 
complex and of no or low flexibility. Further, the resource allocation is found to 
be cumbersome and difficult, and is often the reason why such systems may 
exhibit severe unreliability situations. 

Another field where the invention may be applied to, are financial trading, 
25 clearing and settlement systems, and more particular the trading, clearing and 
settlement of collateralised money (credit) contracts in the repo (repurchase 
agreement) market. 
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A Repurchase Agreement (repo) is the sale of securities by one party (the 
seller of securities or cash taker) to another (the buyer of securities or cash 
provider) with the added conditions that those securities or those similar to it 
will be resold at a given price at a specified future date. In terms of the 

5 security aspects there are two main types of repos that can be differentiated: 
General Collateral (GC) repos and Special repos. A GC repo defines the 
sell/buy of a basket of securities, a Special repo contract implies a specific 
security. Securities of the same quality are grouped to a basket. For instance, 
a German government basket consists of securities with the quality German 

10 government bonds. The credit default risk of a security is the dominant 
grouping criteria. 

The repo participants of a GC repo trade agree on a credit risk or credit rating 
of a security basket. A single repo contract is legally embedded in a legal repo 
master agreement between the two repo parties. Within a specific repo trade 
15 the contracting partners agree on: sell or buy of securities, security or basket 
of securities, nominal amount (size of security/basket), purchase date, 
repurchase date, and repo rate (interest rate between start and closing 
period). 

The type and quality of the traded securities are in principal a negotiation topic 
20 between the repo contract partners, in practice most of the repo traded 
securities are bonds with high credit ratings. 

The repo transactions can further be grouped by the trading motivation into a 
funding or cash driven and security driven group. 

Basically when the cash funding aspects of a repo trade are in the foreground, 
25 the trading participants agree to deliver a basket of securities (GC repo) 
instead of a specific security (Special repo). The basic intention of a GC repo 
trade is to fund the cash requirements on a low interest rate (repo rate). 
Concerning the cash flow perspective a repo basket transaction is similar to a 
loan contract with a fixed interest payment at the end of the credit period and 
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defined loan collaterals. A GC basket with a high creditworthiness (low credit 
default risk) ensures a favourable credit term on the repo market. 

Discussing now the repo market organisation, the repo market participants are 
mostly commercial banks and/or institutional investors in the short-term capital 
5 market (money market segment). The repo market is either organised 
bilaterally, i.e. repo participants 100, 110, 200, 220 trade directly over phone 
with each other (as shown in the conceptional representation of FIG. 1), or 
anonymously and standardized via the electronic platforms of an institutional 
trading system and clearing house 210 (for high-level abstraction see FIG. 2). 

10 In case of a standardized market organisation via a trading system and 
clearing house organisation, as shown in FIG. 3, the electronic trading system 
320 acts in general as an independent information broker whereby the clearing 
house 210 acts as a central counterparty in order to reduce counterparty risk. 
Therefore the typical trading workflow is structured such that the market 

15 participants 200, 220, 300, 310 quote e.g. a repo basket within an anonymous 
and public quote book of the electronic trading system. As soon as a market 
participant accepts one of the binding quotes the clearing house 210, 330 
steps in the repo contract. If a clearing house 210, 330 acts as an central 
counterparty the dedicated trade participants dispose an obligation only 

20 against the clearing house. After the trading (and clearing) processes the repo 
trades are settled within a security and cash custody organisation 340. 

The mentioned settlement organisation 340 embraces various institutions: a 
central security depository (CSD) that stores physically the securities and 
manage the corresponding property rights assignment within their account 

25 system; a corresponding security custodian that participates on the CSD 
account system (a corresponding custody bank is not necessary if the repo 
participant holds a CSD account); a corresponding cash custodian that 
participates on the centralised payment and cash account system (typically the 
repo banks and CSD holds directly payment and billing accounts within the 

30 central bank account system); and settlement departments inside the banks 
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that supervise and manage the movements on their cash and security 
accounts. 

The trading workflows arrange the mutual agreements process between the 
repo partners, and the settlement cycles assure the physical fulfilment on the 
5 committed contracts. In the following, the repo basket trading via a trading 
organisation is described in more detail. 

FIG. 4 illustrates how conventional systems perform traded repo transactions. 

Banks assess their financial requirements (either in cash or securities) within 
their internal position keeping systems. To fund short positions the repo 
10 basket trader has to assure the availability of suitable collateral. To ensure the 
right collateral quality and quantity several steps 410, 420 have to be 
performed by each trading member: validate the actual positions of available 
securities; group the securities into the collateral types; and assign and 
allocate collateral to the dedicated repo basket definition. 

15 First, there is an initial step 400 where the repo trader starts the negotiation 
and funding process. One market participant quotes for a basket offer, and 
another participant agrees to the transaction. Then, the securities are pooled 
from the existing collaterals in step 410, and allocated to basket trades in step 
420. The pooling process 410 receives as input parameters the sum of all 

20 available collateral/security stocks. These are then grouped according to the 
respective basket criteria. The pooling step 410 then outputs the basket 
structures containing the securities. In the allocation step 420, the securities 
of the respective baskets are allocated in accordance with the basket 
definition. Allocation takes place as long as the nominal of the intended repo 

25 transaction or quoting is not yet reached. 

After balancing the collateral positions, bid and ask offerings are published 
and finally accepted via an electronic trading platform. 

The clearing house 210, 330 acts as a central counterparty for all repo trades. 
By replacing the original counterparties in a repo trade, the central counterpart 
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assumes all the credit risk exposure. The workflow is organized in a way that 
two market participants agree on the contract details published on exchange, 
the trade details are transmitted to the clearing system, and the clearing 
system closes on the basis of the origin trade details laterally reversed 
5 contracts with the repo participants and provides the corresponding deal 
confirmations (step 430). 

Following the deal closure, the clearing house 210, 330 generates settlement 
instructions from the trade details in step 440. These settlement instructions 
are then used in the settlement process or system to start the process 480 of 
10 disposing the accounts of the central security depository for clearing members 
with respect to the resulting security credit or debit situation, and posting the 
securities in the general ledger as well as initiating the cash movements to the 
accounts. 

It is to be noted that the clearing members need not necessarily be the market 
15 participants (or trade participants) themselves. In cases where the clearing 
members are different entities, the generation of settlement instructions may 
become more complex. 

Further, a risk margin may be calculated in step 450 in order to cover the 
clearing house credit risk against their trade counterparties. The risk margin 
20 requirements are compared in step 460 to margin-collateral pool positions. 
The clearing system 210, 330 then generates on the basis of the deal details 
the settlement instructions for corresponding margin-collateral accounts in step 
470. 

Within the clearing organisation each single security position of a repo basket 
25 is processed like an independent repo trade. Therefore a repo basket trade 
with e.g. five different underlying securities results into five separate and 
independent repo trades and settlement instructions 

Also just after the repo deals are finalised, the contract participants (clearing 
house 210, 330 and market participant 300, 310) generate the corresponding 



settlement instruction and instruct their cash and security correspondence to 
settle the dedicated cash and security movements. For example if repo 
market participants "A" and "B" agree on a repo trade thafA" (cash taker) 
receive a cash credit from "B M (cash provider) respectively "A" delivers a 
5 basket of securites (as collateral) to "B" the settlement process and instruction 
for the purchase transaction would be like: "A" delivers the dedicated securities 
to the clearing house; the clearing house transfers the cash amount (credit) in 
favour of "A"; the clearing house delivers the securities further to "B", and "B" 
transfers the cash amount to the clearing house. 

10 The settlement structure of the repurchase transaction is laterally reversed to 
the purchase structure. That is, the double-ended arrows in FIGs. 1 and 2 are 
intended to illustrate the credit (and interest) flow in one direction and the 
security flow in the other direction, for both the purchase leg and the 
repurchase leg. 

15 The structure of the described settlement cycle follows a delivery versus 
payment (DVP) method. DVP settlement incorporates an interdependence 
between the cash and security settlement cycles and starts typically with the 
delivery of the security side. The advantages of a DVP settlement within a 
clearing house structure consist out of an improved settlement guaranty for the 

20 market participants because of the central role of the clearing house and their 
high creditworthiness. The disadvantages of a DVP process results out of the 
different time schedule of the cash and security settlement cycles. A 
mismatch of timing is basically founded on the technical organisation of bulk 
processing within the cash and security settlement cycles. Typically the cash 

25 settlement cycles are much more flexible or near-time organised than the 
security settlement cycles. 

As in the memory and processing time examples discussed above, the main 
disadvantage of the prior art repo techniques is that the definition of such 
transfers is usually rather complex and of insufficient flexibility. Further, the 
30 security allocation is often cumbersome and difficult. 
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SUMMARY OF THE INVENTION 

An improved repo basket transaction and resource management system and 
method for controlling the transfer of groups of resources is provided, that may 
overcome the disadvantages of the prior art techniques. 

5 According to an embodiment, a repo basket transaction system is provided 
that comprises a trading system connected to receive repo quotes from market 
participants. The repo quotes specify a repo basket transaction by constituting 
a security basket definition indicating a security amount and at least one class 
of securities. The system further comprises a settlement system connected to 
10 receive settlement instructions relating to repo basket transactions. The 
settlement system comprises a securities pooling and allocation unit adapted 
to investigate the security basket definition relating to a repo basket 
transaction and allocate at least one individual security that meets at least one 
class of securities indicated by the investigated security basket definition. 

15 According to another embodiment, there is provided a settlement system 
capable of being operated in a repo basket transaction system. The 
settlement system is connected to receive settlement instructions relating to 
repo basket transactions specified by constituting a security basket definition 
indicating a security amount and at least one class of securities. The 

20 settlement system comprises a securities pooling and allocation unit adapted 
to investigate the security basket definition relating to a repo basket 
transaction and allocate at least one individual security that meets at least one 
class of securities indicated by the investigated security basket definition. 

According to a further embodiment, a repo basket transaction method is 
25 provided that comprises receiving repo quotes from market participants. The 
repo quotes specify a repo basket transaction by constituting a security basket 
definition indicating a security amount and at least one class of securities. The 
method further comprises investigating the security basket definition relating to 
the repo basket transaction, and allocating at least one individual security 
30 according to given settlement amounts. The at least one individual security 
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meets at least one class of securities indicated by the investigated security 
basket definition. 

According to yet another embodiment, there is provided a resource 
management system for controlling the transfer of groups of resources. The 

5 system comprises an input unit for receiving transfer instructions. The transfer 
instructions specify a transfer of a group of resources by constituting a 
definition indicating at least one class of resources and at least one condition 
under which, after the transfer has been completed, a reverse transfer of the 
same group of resources or another group of resources within the same at 

10 least one class of resources has to occur. The system further comprises a 
resource specification unit for investigating the definition and allocating 
individual resources for the transfer that meet at least one class of resources 
indicated by the investigated definition. 

According to still a further embodiment, a resource management method of 
15 controlling the transfer of groups of resources comprises receiving transfer 
instructions specifying a transfer of a group of resources by constituting a 
definition indicating at least one class of resources and at least one condition 
under which, after the transfer has been completed, a reverse transfer of the 
same group of resources or another group of resources within the same at 
20 least one class of resources has to occur, investigating the definition, and 
allocating individual resources for the transfer that meet the at least one class 
of resources indicated by the investigated definition. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings are incorporated into and form a part of the 
specification for the purpose of explaining the principles of the invention. The 
drawings are not to be construed as limiting the invention to only the illustrated 
5 and described examples of how the invention can be made and used. Further 
features and advantages will become apparent from the following and more 
particular description of the invention, as illustrated in the accompanying 
drawings, wherein: 

FIG. 1 is a block diagram illustrating the principle of a bilaterally organized 
10 repo trade; 

FIG. 2 is a block diagram illustrating the principle of a traded repo trade; 

FIG. 3 is a block diagram illustrating the process areas and data flows of a 
conventional traded repo transaction; 

FIG. 4 is a flow chart illustrating the workflow of a conventional traded repo 
15 transaction performed in the system of FIG. 3; 

FIG. 5 is a block diagram illustrating the process areas and data flows of a 
traded repo transaction in a pool trading system according to an embodiment; 

FIG. 6 is a block diagram illustrating in more details the components of the 
collateral management system that is part of the pool trading system of FIG. 5; 

20 FIG. 7 is a flow chart illustrating the workflow of a traded repo transaction 
performed in the system of FIG. 5, according to an embodiment; and 

FIG. 8 is a block diagram illustrating an extension of the pool trading system of 
FIG. 5 enabling online operation. 
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DETAILED DESCRIPTION OF THE INVENTION 

The illustrative embodiments of the present invention will be described with 
reference to the figure drawings wherein like elements and structures are 
indicated by like reference numbers. 

5 According to the embodiments, the transfer of groups of resources is initiated 
by transfer instructions. The transfer instructions specify the transfer of a 
group of resources by constituting a definition indicating at least one class of 
resources and at least one condition under which, after the transfer has been 
completed, a reverse transfer of the same group of resources or another group 

10 of resources within the same at least one class of resources has to occur. 
That is, the group is not specified by defining the individual resources but by 
defining one or more classes of resources. This group definition then allows 
for processing the group as single "synthetic" resource in much the same way 
as a common resource. 

15 According to the embodiments, a central resource specification unit 
investigates the definition and allocates individual resources for the transfer 
that meet the class definition. Thus, the resource allocation is no longer be 
done decentralized in the various transfer instructions, but by a central entity in 
the course of processing the defined groups. 

20 While not limited to the example of resource groups being repo baskets, the 
following embodiments will focus on the field of processing repo basket 
transactions. 

As will be more apparent from the following description, these embodiments 
target to improvements of the cash funding facilities of the repo market by 
25 improvements in the basket handling and collateral management within GC 
repo workflow. The repo basket trading constitutes the development of a 
trading, clearing and settlement infrastructure as shown in FIG. 5 which is 
capable to process a "synthetic" basket security. 
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As will be described in more detail below, the functional set up according to 
the embodiments is enhanced by three additional elements: 

• a synthetic security as collateral basket, 

• a centralised allocation function, and 

5 • earmarking as novel settlement function. 

In context of the repo business a synthetic security is developed to define a 
generic (collateral) basket. The synthetic security represents a defined 
security quality or class of securities. As mentioned above the common 
security classes within the repo market may be government bonds, mortgaged 
10 bonds and bonds issued by public law corporations. 

A centralised allocation function is used to allocate specific securities to a 
collateral basket or synthetic security. This function is relocated from the 
workflow environment of the trading departments to the centralised settlement 
environment. 

15 Earmarking describes a process where security positions are posted in favour 
of the beneficiary without booking the dedicated repo participant's general 
ledger accounts. 

Turning now to FIG. 5, a block diagram is provided illustrating the process 
areas and data flows of a traded repo transaction according to an 

20 embodiment. Market participants operate client devices 500, 510 to make 
quotes and lift/hit quotes. Such transfer instructions may include repo basket 
definitions containing class information. Unlike in the prior art of FIG. 3, the 
electronic trading system 520 is now capable of dealing with such transfer 
instructions. Further, also the clearing system 530 is adapted to handle the 

25 novel kind of transaction definitions. 

The centralised allocation function mentioned above is then mainly realized by 
a settlement system 560 which comprises a disposition and booking system 
550 and a collateral management system 540. The disposition and booking 
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system 550 receives and identifies the settlement instructions, and transfers 
the identified settlement instructions to the collateral management system 540 
for earmarking purposes. 

The settlement system 560 is generally arranged to perform disposition of 
5 securities as well as cash movements. When booking securities, the 
disposition and booking system 550 uses internal booking procedures which 
administer the security positions. When booking cash movements, the 
disposition and booking system 550 merely uses some mirroring accounts. 
The final cash booking is done in an external (but connected) cash settlement 
10 system 570 which comprises a disposing system 572 and a cash booking 
system 574. 

The settlements system 560 may further interact with a central security 
core/market data system 580 that comprises a static data storage 582 and a 
market data storage 584. 

The collateral management system 540 is depicted in more detail in FIG. 6 as 
comprising a pooling unit 630, an allocation unit 640, and an earmarking unit 
650. The pooling unit 630 has access to a collateral sub-ledger 600. The 
allocation unit 640 has access to an allocation rules storage 610. Units 630 
and 640 may be understood to form a resource specification unit that handles 
the pooling as well as the actual allocation. The earmarking unit 650 is 
capable of creating and accessing a collateral sub-ledger 620. 

The central pooling unit 630 receives the basket settlement instructions and 
selects and groups securities from the collateral pool 600 of the respective 
market participant in accordance with the traded synthetic basket as identified 
25 by the input parameters. For this purpose, the pooling unit 630 may import 
basket definitions from the basket criteria/rules storage 660 and retrieve the 
available collaterals of the participant. It is to be noted that the collateral pool 
600 may include available entries of the collateral account of the participant as 
well as those entries which have been earmarked for this participant. 
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The allocation unit 640 receives from the pooling unit 630 data indicating the 
basket qualified part of the collaterals. Further, the allocation unit 640 receives 
allocation rules from storage 610. In addition, the allocation unit 640 receives 
the value of the repo instruction, i.e., the trade volume of the repo transaction. 

5 Using the allocation rules for the collaterals, the allocation unit 640 generates 
a priority list of the used securities. Then, the allocation unit 640 allocates the 
available and qualified collaterals to the requested settlements amounts. For 
this purpose, the collaterals are valued based on market prices as retrieved 
from the market data storage 670. Allocation stops when the requested 

10 settlements amount is adjusted to the market prices of the cumulated 
collaterals. 

The allocation unit 640 outputs to the earmarking unit 650 information on the 
securities, and allocation instructions which indicate the security volume to be 
allocated. The earmarking unit 650 adds to the securities unique informatin 
15 indicating the respective security ownership. The earmarking initiates booking 
the earmarking transfers, i.e. the respective securities, to the sub-ledger 
account 620. This includes referencing of securities which have been 
transferred by earmarking, to the original owner or collateral account. 

It is to be noted that by implementing a central contractor, two independent 
20 (sale and purchase) settlement instructions are generated relative to the 
central contractor. For instance, one market participant transfers a security to 
the central contractor, and the central contractor transfers the security to the 
other market participant. Of course, the cash flow is organized similarly, but in 
the other direction. The settlement of security transactions may start with the 
25 security transfer to the central contractor, i.e. one market participant transfers 
a security to the central contractor, and the central contractor transfers cash 
back. Then, the central contractor transfers the security to the other market 
participant, and the other market participant transfers cash back to the central 
contractor. That is, the collateral of the selling market participant, i.e., the cash 
30 taker, is earmarked to the security account of the central contractor in a first 
step, and is then earmarked to the security account of the other market 
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participant, i.e. the purchaser of cash provider, in a second step. It is to be 
noted that both earmarking steps may be performed in sequence but without 
notable time delays. 

The operation of the various units shown in FIGs. 5 and 6 will become 
5 apparent from the following description with reference to FIG. 7. 

As apparent from FIG. 7 when compared with FIG. 4, there are no initial 
pooling and allocation steps 410, 420 in the present embodiment. Rather, the 
process directly continues with steps 705-725 which substantially correspond 
to steps 430-470 of the conventional process shown in FIG. 4. Further, it is 
10 apparent that the final step 480 of disposing and posting securities and 
performing cash movements to accounts in the process of FIG. 4 is replaced 
by a novel procedure (steps 730-770) which also handles the pooling and the 
allocation. 

As may be seen from FIG. 7, this procedure starts with identifying the 
15 settlement instructions for the respective synthetic basket transactions in step 
730. Then, the process may be split to separately handle the securities in 
steps 735-745, and the cash flow in steps 750-760. This separation is similar 
to the split between step 710 (or 440) and steps 715-725 (or 450-470). 

In detail, the securities processing comprises the pooling of the collaterals 
20 according to the basket criteria in step 735, the allocation of the collaterals 
according to the settlement instructions in step 740, and the earmarking of the 
allocated collateral positions in step 745. The cash settlement comprises the 
step 750 of disposing the cash requirements, the step 755 of reserving cash 
amounts on central bank accounts, and the step 760 of confirming the cash 
25 reservations. Finally, the sub-ledger securities are posted in step 765, and the 
cash accounts are posted in step 770. 

To summarize the GC pooling workflow design of the present embodiment, 
this environment provides to the repo industry the opportunity to trade a 
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collateral basket like a synthetic security. The basket is processed throughout 
the value chain as a single security. 

Within the described process organisation, a repo trader 500, 510 defines only 
the intended security class in form of a generic basket instead of a bunch of 
5 single securities (step 700). The trading platform 520 transfers the repo 
basket deal details to the clearing environment 530. The clearing house 530 
steps in the repo contracts as a central counterparty and generates deal 
confirmations for the delivery and/or acceptance of a synthetic security (step 
710). Hereafter the risk margins will be calculated in step 715 on the basis of 
10 the synthetic security (basket). Within the risk calculation process, the risk 
profile of a synthetic security is treated as an average risk profile of the 
dedicated security class. 

The settlement process is activated by the settlement instructions. The 
settlement instructions are produced in steps 710 and 725 out of the clearing 
15 process and instruct a delivery versus payment in reference to the defined 
synthetic security (basket) transaction. Within the settlement process, 
securities which meet the required security quality will be allocated in step 740 
out of eligible security or collateral pool of the repo participant 500, 510. 

This allocation method performed in unit 640 manages the allocation of 
20 securities into the basket automatically based on standardised rules 610. The 
allocation process uses a security (collateral) pool 600, 630 which may be 
defined in advance by the dedicated settlement departments of the banks. 
These collateral pools are defined in general for collateralised trading. 

After the allocation process is finished, the defined security positions are 
25 earmarked in step 745. The Earmarking process performed in unit 650 
creates a sub-ledger 620 and post the security movements of a generic basket 
settlement in the sub-ledger 620 in step 765. The technical workflow of 
managing the sub-ledger accounts is independent from the general ledger 
workflows which is managed within the existing settlement process. 
30 Therefore, the sub-ledger posting and processing is independent from the 
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existing settlement time schedules on the general ledger accounts. The 
earmarking process incorporates a full passage of the title and can be 
processed on a real time or at least near time basis. 

Referring to FIG. 8, in another embodiment, the collateral management system 
5 540 may be connected to one or more client devices 800 for allowing 
participants in the backoffice or in collateral management departments of the 
participating banks to obtain information with respect to the GC pooling online, 
and/or to input data for controlling the process. The clients 800 may generate 
substitution instructions and issue these instructions to the collateral 
10 management system 540. A substitution instruction may generally be used for 
substituting blocked securities for available and qualified securities. Blocked 
securities in this context are securities which have already been allocated and 
earmarked. A substitution instruction may comprise at least an identification of 
the securities to be substituted and the respective volume. 

15 Referring now back to FIG. 6, allocation rules are stored in storage unit 610. 
The purpose of the rules is to allow allocating free and eligible securities which 
can be secured. Allocation rules may also serve the opposite function, i.e the 
release of allocated securities. 

The process may be to follow certain sorting criteria and may be triggered by 
20 certain client events. It may also be run during an overnight batch processing 
as a result of the re-evaluation of allocated securities. 

The automatic allocation may consist of three functional subitems namely its 
algorithm, its information storage for documentational reasons, and its being 
triggered by (later on defined) events. In addition, the non-functional 
25 requirements may be referenced as another subitem. 

In the selection algorithm, each automatic allocation process may be followed 
by an automatic release process in order to reduce an unnecessary 
overcoverage and to release non-eligible securities. The automatic release 
process may be such that it must never lead to an undercoverage or increase 
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of an existing undercoverage. Further, the allocation algorithm may be such 
that it must only choose among the free securities which are eligible. 

As for the release algorithm, the allocated securities which are not eligible at 
the processing time may be considered as having security value 0. In an 
5 embodiment, if and only if the covering ratio of the claim to be secured is 
greater than or equal to 100%, these collaterals must be released 
automatically. 

In the following, the sorting criteria of the present embodiment are described in 
more detail. For the automatic release process holds/is valid, and within the 

10 amount criterion, the sorting hierarchy may prefer the securities for which the 
security value, a multiple of the lowest tradable unit, fits best (i.e. the security 
value is smaller but as close as possible to) the current overcoverage. This 
multiple may be released in each step. Whenever two securities are equally 
ranked, the one with the highest security identification number may be chosen. 

15 The release of securities with security value 0 may always precede the release 
of securities with positve security value. 

The amount criterion may be the first criterion for the allocation process. For 
each selection step, the allocation algorithm may prefer the free eligible 
collateral, the securitiy value of which fits the undercover. Its own inner criteria 
20 may be the exact coverage, the minimization of the overcoverage, and the 
minimization of the undercoverage. 

For the exact coverage criteria, the allocation process may prefer free eligible 
securities which meet exactly the current undercoverage (i.e. the 
undercoverage in each step). If more than one collateral satisfy this criterion, 
25 the process may choose the one with the lowest security identification number. 

For the minimize overcoverage criteria, among all free eligible securities which 
have a security value which is greater than the current undercoverage, the 
process may prefer the collateral with which the smallest possible 
overcoverage is reached regarding each collaterals lowest tradable unit. This 
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need not be the one with the smallest lowest tradable unit. For example, if the 
undercoverage is 999 EUR there may be two eligible securities both with a 
security value greater than 999 EUR. For security A, the lowest tradeable unit 
is for instance 1, and the price is 700 EUR. For security B, the lowest 
5 tradeable unit is for instance 100, and the price is 10 EUR. For security A the 
overcoverage would be 401 EUR, for security B it would be 1 EUR. In this 
case security B would be allocated. Generally, if more than one collateral 
satisfy the minimize overcoverage criterion, the process may choose the one 
with the lowest security identification number. 

For the minimize undercoverage criteria, among all free eligible securities 
which have a security value smaller than the current undercoverage of the 
claim to be secured, the automatic allocation may choose the one with the 
biggest security value. If more than one collateral satisfy this criterion, the 
process may choose the one with the lowest security identification number. 

The automatic allocation may end when either there is no undercoverage or 
the security pool does not contain free eligible securities any more. If there is 
sufficient coverage or overcoverage after the automatic allocation, the 
automatic release process may be triggered (see below), whereas in the latter 
case when there is still an undercoverage, the automatic process may need to 
change the relevant amount, i.e., the global amount. 

The automatic release process may end when the overcoverage cannot be 
reduced any more regarding the lowest tradable unit of the allocated 
securities. 

25 Depending on the security identification number, the automatic allocation 
process may reduce the free nominal value of the collaterals to be allocated 
while it creates new allocations or increases the allocated nominal value 
depending on the security identification number. In case of releases, the 
process may increase the free nominal value und decrease the allocated 

30 nominal. If the allocated nominal value has decreased to 0, the allocation may 
be deleted. 
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If a collateral loses its eligibility, its security value may be set to 0. Allocated 
securities may only be released if there is sufficiently coverage. 

If the automatic allocation process fails to provide a sufficient coverage, it may 
reduce the global amount to the sum of security values over all collaterals 
5 which are currently allocated. The global amount reduction by the automatic 
allocation process may result in a new version, and may be reported through 
the special reports. 

At the end of each complete automatic allocation or release process, the 
covering ratio may be updated automatically. 

10 In the following, automatic allocation triggers are described in more detail. 
These triggers are in the present embodiment that securities become 
securable, and that there is a periodical re-evaluation. 

A non-historic version may become securable when it enters a predefined 
state and the re-evaluation detects an undercoverage. This trigger may 
15 include the "lifting" to a contract's new version. An undercoverage may occur 
for the first version, when the global-amount has been increased, a haircut for 
an allocated security has been increased, or simply the value of an allocated 
security has fallen. 

In the periodical re-evaluation, if a nightly re-evaluation of collaterals detects 
20 an undercoverage, the automatic allocation may be invoked upon it. 

Besides automatic allocation triggers, there may be automatic release triggers. 
These triggers are in the present embodiment that securities become 
securable, there is an automatic allocation, and there is a periodical re- 
evaluation. The functions and conditions of these triggers are similar to the 
25 automatic allocation triggers described above. 

The changes to the security pool may be documented in detail. Since no client 
changes may be possible, the automatic process 1 results may be shown 
analogously to the results due to the manual allocation and release. Hence 
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the automatic process may result in allocation instructions which are created 
and controlled automatically by the system. 

The allocation instructions may sum up the actions (i.e. allocations or 
releases) due to the allocation or release process. If the sum of all allocations 
5 or releases chosen by the automatic process is greater than a predefined 
value, the process may create more than one allocation instruction, because 
the number of transaction positions per allocation instruction is limited to this 
predefined value. The predefined value may for instance be 50. 

Since the automatic release may possibly rely on the results of the automatic 
10 allocation, allocations and releases may result in disjoint allocation 
instructions. Thus, allocations and releases may then never be reported 
together in a single instruction. 

After the instruction has been created, it may be controlled, executed and set 
to historic automatically by the system. The allocation instructions created by 
15 the automatic process may be marked as automatic allocation or release 
instructions by setting each action's user information to a predetermined user- 
id. 

The automatically created instructions may be given an instruction number 
which is greater than or equal to one and smaller than or equal to a predefined 
20 maximum number, which is, e.g., 799999. These numbers must be unique for 
the predetermined user-id among all non-historical booking and allocation 
intructions numbers created by this user-id. All automatic allocation and 
release instructions may be numbered starting from one each day. 

The reports and views created for the manual allocation or release process 
25 may also be used for the automatic allocation. The distinction between 
manual and automatic allocations is possible by the predetermined user-id for 
creation and control whenever these fields are displayed. 

As mentioned above, the clearing unit 530 performs, inter alia, the generation 
710, 725 and management of settlement instructions. In an embodiment, the 
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settlement instruction generation process comprises a mechanism to split 
settlement instructions into two or more settlement instructions of smaller 
value. For instance, if the value of a settlement instruction that is to be 
generated would exceed a predefined threshold, e.g. 50,000,000.00 euro, a 
5 number of settlement instructions will be generated that are each of smaller 
values below or equal to this threshold. In the present embodiment, the split 
mechanism generates as many settlement instructions of the threshold value 
as needed, and one final settlement instruction for the remaining amount, if 
any. 

10 In a further embodiment, the prices of the electronic trading platform 520 are 
delivered in realtime to a price distribution tool for processing the data and 
sending the processed data to external data dealers. The price distribution 
tool may contain the following functions: a quote listener, a quote and/or data 
manager, and a quote and/or data distributor. The quote listener rebuilds the 

15 quote book logic to determine the best quote using predefined rules, to handle 
virtual listings, and to generate cancellation messages. The quote/data 
manager consolidates the quotes or data to conform with a generic data 
format, and provides for recover capabilities. The quote/data distributor 
generates primary keys representing logic listings, divides the markets and 

20 currencies, and introduces purchase and repurchase dates as part of the 
identifying primary keys, thereby generating a logic listing. 

For example, there may be about 90.000 combinations of purchase/re- 
purchase dates for a GC security, but only a small number of such 
combinations are posted, for example 300 each. Each day, 300 new 
25 combinations are added, and 300 existing combinations are rendered 
impossible. While generally usable for quotes, this mechanism can be used 
for trades as well. 

In the present embodiment, bid and ask quotes are traded in separate order 
books. Based on the order book in logic listings, the best item is selected in 
30 accordance with the respective rules, such as price, volume, and seniority. 
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This can be done in close analogy to the respective determination in the 
electronic trading system. 

As an alternative, calculations can be made on the basis of individual logic 
listings, such as the sum of all quotes, or a weighted average. The generation 
5 of the market depth can be based on the logic listings. Further, other possible 
schemes are, e.g, yield curves where prices relating to the same terms or 
currencies (e.g. two weeks) can be considered and consolidated at several 
time instances (e.g. two weeks starting tomorrow, or two weeks starting next 
month). 

10 While the invention has been described with respect to the physical 
embodiments constructed in accordance therewith, it will be apparent to those 
skilled in the art that various modifications, variations and improvements of the 
present invention may be made in the light of the above teachings and within 
the purview of the appended claims without departing from the spirit and 

15 intended scope of the invention. 

For instance, embodiments are particularly applicable wherever a transfer and 
the corresponding reverse transfer are bi-directional transfers (such as, in the 
specific example of a repo basket trade, a purchase) comprising a transfer of 
the respective group of resources in one direction (for instance a repo basket) 
20 and a transfer of a respective other resource in the opposite direction (for 
instance cash in the amount of the agreed basket price). 

Further, the resource group definition may indicate a quantity of resources 
(such as a security amount) describing the resource volume of the group of 
resources. 

25 The predefined rules may specify the manner in which the allocation takes 
place, for instance dependent on the availability of resources (or securities). It 
is however to be noted that other rules may likewise be applied. 

For instance, the storage 600 may be arranged for storing data indicating the 
individual resources in association with data indicating the at least one class of 
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resources, and the pooling unit 640 is adapted to access this storage for 
allowing the allocation 630 to allocate the individual resources based on the 
predefined rules stored in unit 610. 

It is further to be noted that the resource management system may be capable 
5 of controlling the transfer of other resources than resources of the above 
described groups of resources. The resource allocation unit 640 then stores a 
first array of resource data to which the other resources are posted after 
allocation, and further stores a second array to which the individual resources 
are posted after allocation. 

10 In addition, those areas in which it is believed that those of ordinary skill in the 
art are familiar, have not been described herein in order to not unnecessarily 
obscure the invention described herein. Accordingly, it is to be understood 
that the invention is not to be limited by the specific illustrative embodiments, 
but only by the scope of the appended claims. 

15 What is claimed is: 



